Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reduce the number of constraints repeated when writing T: SomeTrait #1927

Closed
wants to merge 1 commit into from

Conversation

sgrif
Copy link
Contributor

@sgrif sgrif commented Feb 24, 2017

@sgrif sgrif force-pushed the sg-visible-where-clause branch from 6dee359 to 79b121f Compare February 24, 2017 17:32
@withoutboats withoutboats added the T-lang Relevant to the language team, which will review and decide on the RFC. label Feb 25, 2017
@nikomatsakis
Copy link
Contributor

There is a rustc bug on this issue as well:

rust-lang/rust#20671

I am generally in favor of this change. I have to give the RFC a detailed read. I am not sure if there are backwards compatibility concerns -- if so I would expect them to arise only in corner cases, but still worth considering.

@durka
Copy link
Contributor

durka commented Mar 6, 2017

Why leave the several exceptions where supertrait bounds would not be inherited? It seems less confusing to inherit everything.

In particular I don't understand the difference between Vec<Self>: Bar and Result<Self, T>: Bar.

@soltanmm
Copy link

soltanmm commented Mar 7, 2017

When it says that Self appearing in the target means that the constraint will be inherited (elaborated?), does that include associated type projections (e.g. Self::Foo: Trait)? Either way, could that be explicitly mentioned?
EDIT: More specifically:

trait A {
    type Foo: X;
}
trait B: A where <Self as A>::Foo: Y {}

Would claiming Bar: B elaborate to Bar::Foo: Y?
EDIT EDIT:
And and and extending off of @durka, elaborating everything would allow the derive macros to do the right thing w.r.t. associated types and type parameters in struct members by just requiring pointwise implementations of the actual member types instead of today's weird undescribable horro- I mean approximation.

@aturon
Copy link
Member

aturon commented Jun 6, 2017

@nikomatsakis Any thoughts on this? Are you inclined to subsume this under a more general implied bounds RFC? Can we mentor someone to write that?

@nikomatsakis
Copy link
Contributor

I am going to close this RFC in favor of #2089, which proposes a more general variant of the design described in here! But please, @sgrif or others, let me know if you see anything that this RFC covered that #2089 does not!

@nikomatsakis nikomatsakis mentioned this pull request Aug 1, 2017
@sgrif sgrif deleted the sg-visible-where-clause branch August 1, 2017 18:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T-lang Relevant to the language team, which will review and decide on the RFC.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants